Traditionally, to securely connect geographically distributed private local area networks (LANs) of an enterprise to each other, hard-wired connections were leased from telecommunication companies, or at least an amount of guaranteed bandwidth on these connections. As well, to connect a single remote user to a private LAN, the remote user would dial in to a dedicated collection of modems, phone lines and associated network access servers. These private LANs are typically used for networking functions (e.g., e-mail, file sharing, printing) within an enterprise. Network connected devices within such a private LAN are not intended to be reachable by devices in other, unrelated networks. Increasingly, the use of Virtual Private Networks (VPNs) is replacing the use of leased hard-wired connections for providing links between LANs and the use of dedicated dial-up lines for providing remote users access to corporate intranets.
VPNs typically use a public data network, such as the Internet, to connect computer systems in private networks that are related to each other. Four critical functions have been identified as being necessary for VPNs to ensure security of data: authentication; access control; confidentiality; and data integrity. To meet these ends, while using a public data network which uses a protocol such the Internet Protocol (IP) for instance, the concept of “tunneling” has been successfully implemented.
Tunneling involves the encapsulation of a sender's data in IP packets. These encapsulated packets hide the underlying routing and switching infrastructure of the Internet from both senders and receivers. At the same time, these encapsulated packets can be protected against snooping by outsiders through the use of encryption techniques.
Tunnels can have two types of endpoints, where an endpoint may be either an individual computer or a LAN with a security gateway, which might be a carrier router or firewall. Only two cases of combinations of these end points, however, are usually considered in designing VPNs. In the first case, LAN-to-LAN tunneling, a security gateway at each end point serves as the interface between the tunnel and the private LAN. In such cases, users on either LAN can use the tunnel transparently to communicate with each other. The second case, that of client-to-LAN tunnels, is the type usually set up for a mobile user who wants to connect to a corporate LAN. The client, i.e., the mobile user, initiates the creation of the tunnel on his end in order to exchange traffic with the corporate LAN. To do so, he runs special client software on his computer to communicate with the gateway protecting the corporate LAN.
In particular, tunneling is described in K. Hamzeh, et al., “Point-to-Point Tunneling Protocol (PPTP)” Internet Engineering Task Force (IETF) Request for Comments (RFC) 2637, hereby incorporated herein by reference, which specifies a protocol that allows the known Point to Point Protocol (PPP) to be “tunneled” through an IP network. A client-server architecture is defined, in RFC 2637, in order to decouple functions which exist in current Network Access Servers so as to support VPNs. The PPTP uses an enhanced Generic Routing Encapsulation mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. The PPTP is designed to run at Open Systems Interconnection (OSI) Layer 2. Layer 2 is the OSI “Data Link” layer and is used to provide reliable transfer of information across a physical link. Tasks performed on the Data Link layer include synchronization, error control and flow control. To be sent on a LAN or wide area network (WAN) link, the payload of an IP packet (i.e., an IP datagram) is encapsulated with a header and trailer for the Data Link layer technology of the outgoing physical interface. For example, if an IP datagram is sent on an Ethernet interface, the IP datagram is encapsulated with an Ethernet header and trailer. When IP datagrams are sent over a point-to-point WAN link, such as in an analog phone network or Integrated Services Digital Network (ISDN), the IP datagram is encapsulated with a PPP header and trailer.
Once the number of endpoints in a given VPN begins to increase, maintaining the given VPN with multiple point to point tunnels may become highly complex. Further, shortcomings of point to point tunneling, that include security threats due to configuration errors and a lack of address separation between the end user IP address space and the carrier IP address space, can become more pronounced.
With regard to the latter of these shortcomings, it is typical for an IP LAN behind a carrier router (i.e., a tunnel endpoint) to have an IP address space that is not meant to be seen by the outside IP world. Such IP addresses may follow a consistent pattern, such as 10.X.X.X. This pattern is often dependent upon the supplier of the networking equipment used to implement the VPN. Hence, by using the same networking equipment, the IP address spaces related to VPNs of different organizations (say, SEARS™ and SPRINT™) may share common addresses. This sharing of common addresses may lead to problems when configuring multiple VPNs over a single carrier network. In particular, a configuration error could lead to packets missing their intended destination in favor of a destination in an unrelated network. For example, a computer behind a carrier router with the VPN identifier 456 may address a packet to a destination with an address of 10.10.2.4 behind a carrier router with the VPN identifier 123. It may be that, due to a configuration error, the packet is sent to a destination with an address of 10.10.2.4 behind a carrier router with the VPN identifier 132.
Consequently, there is a need for a tunneling scheme that can better cope with shared end user IP address spaces, reduces Layer 2 complexity and minimizes security threats due to configuration errors.